For each version of an operating system (OS), there are corresponding versions of applications. For example, a 16-bit application is designed to run on a 16-bit OS (such as Microsoft® Windows 3.1®). An example of another version is a 32-bit application, which is designed to run on a 32-bit OS (such as Microsoft®Windows® 98).
Specific versions of applications are designed to operate under a specific version of a specific OS. Furthermore, that specific version of a specific OS is designed to operate with specific computing hardware (such as a specific microprocessor).
For example, Microsoft® Office 2000 is an application designed to operate on 32-bit versions of operating systems from the Microsoft Corporation. Examples of such 32-bit operating systems include Windows® 2000, Windows NT® 4.0 (and earlier), Windows® 98, and Windows® 95. The 32-bit OSs are designed to operate on 32-bit compatible processors using an 32-bit instruction set (such as the Intel™ Pentium™, Pentium II™, and Pentium III™).
“Version”
Herein, a reference to a “version” of a program module (such as an application) refers to a class of module that is designed to run under a level of operating system that is different than a previous version of the same program module. A new release of a program model is considered a new “version” when it is more than an incremental improvement and change.
For example, Microsoft® Word 95 is a version of the application that is different from Microsoft® Word 6.0. This is because Microsoft® Word 95 is designed to run on 32-bit OSs (such as Microsoft® Windows® 95 or later version), but it cannot run on 16-bit OSs (such as Microsoft® Windows® 3.1). Conversely, Microsoft® Word 97 is not a different version from Microsoft® Word 95 because both are designed to work on 32-bit OSs like Microsoft® Windows® 95.
A program module may be considered a different version if it uses a different fundamental basis than its previous incarnation. For example, program modules use submodules such as a Dynamic Link Library (DLL) or Application Program Interfaces (APIs). A new program module is a new version if it utilizes a different family of DLLs and APIs than what the previous implementation of such module used.
This same versioning terminology applies to any program module, such as an application, operating system, etc.
Interoperability and Compatibility
Each version of an OS has its corresponding body of applications that are designed to run under it. When a new version of an OS is released, software developers generally upgrade their products to a new version designed to run under the new OS. Software developers do this for many reasons, including marketing, technology, and economics.
For similar reasons, OS developers wish to make their products backwards compatible. In this way, older versions of applications will run on the latest version of the OS. This encourages users to purchase the new OS because they are not forced to discard their current applications and purchase new versions. This also gives software developers time to provide upgrades to their applications.
Configuration
Configuration is the way a system is set up, or the assortment of components that make up the system. Configuration can refer to either hardware or software, or the combination of both. For instance, a typical configuration for a PC consists of 32 MB (megabytes) main memory, a floppy drive, a hard disk, a modem, a CD-ROM drive, a VGA monitor, and an operating system.
Many software products require that the computer have a certain minimum configuration. For example, the software might require a graphics display monitor and a video adapter, a particular microprocessor, and a minimum amount of main memory.
When a person installs a new device or program, she sometimes needs to configure it, which means to set various switches and jumpers (for hardware) and to define values of parameters (for software). For example, the device or program may need to know what type of video adapter you have and what type of printer is connected to the computer. Thanks to new technologies, such as Plug-and-Play, much of this configuration is performed automatically.
Configuration Databases
Software applications typically employ one or more configuration databases to store configuration settings. Under some OSs (such as Windows® 3.1 and MS-DOS®), multiple configuration databases were used by the OS and the applications. There were files for starting the system (e.g., CONFIG.SYS and AUTOEXEC.BAT). There were files for connecting to a network (e.g., NETWORK.INI). There were files for running applications (e.g., WIN.INI and SYSTEM.INI).
Each configuration file had its own rules and structure. Maintaining these files was a difficult chore for the OS. Providing a limited degree of synchronization between these files was also a difficult chore for the OS.
Common Configuration Data Structure
With the advent of more advanced OSs (such as Windows NT® and Windows® 95), a common configuration data structure was introduced. It is called the “Registry.” All configuration settings are stored therein (except for other legacy configuration files that remained for backward compatibility reasons).
Herein, a common configuration data structure refers to a set of multiple configuration databases used by more than one version of a program module (such as an application). In addition, a common configuration data structure refers to a single configuration database (such as the Registry) used by more than one version of a program module (such as an application). A configuration database is often stored as one or more configuration files on the storage system of a computer.
The Registry. Certain OSs store and check the configuration information (herein, “config-info”) at a single location—called the registry. Most applications write data to the registry, at least during installation. The registry is an example of a common configuration data structure.
The registry is a hierarchically structured database containing subtrees of keys that contain per-computer and per-user databases. Each key may contain data items called value entries and may contain subkeys. In the registry structure, keys (and subkeys) are analogous to directories and value entries are analogous to files.
The registry may include the following major sections (i.e., subtrees):                HKEY_Classes_Root—file associations and OLE information        HKEY_Current_User—all preferences set for current user        HKEY_User—all the current user information for each user of the system        HKEY_Local_Machine—settings for hardware, operating system, and installed applications        HKEY_Current_Configuration—settings for the display and printers        HKEY_Dy_Data—performance dataCompatibility Problem        
Herein, compatibility refers to different versions of the same program module peacefully co-existing on the same system. A new version of a program module is said to be backward compatible if it can use files and data created with an older version of the same program.
Often different versions of an application store their config-info in a common configuration data structure. In fact, different versions of an application typically store their config-info at the exact same location within a common configuration data structure.
A later installed version may overwrite existing config-info for an earlier installed version. As a result, the earlier version is unlikely to run correctly (or at all) because its config-info has been changed. Sometimes residual config-info exists in the common configuration data structure and it may interfere with the smooth performance of the later installed version.
By way of example, APIs and DLLs are an area where changes in config-info can greatly affect the performance and/or the operation of different versions of an application using a common configuration data structure. If the later version refers to a family of APIs and/or DLLs that are incompatible with the earlier version, then the earlier version is likely to cause operation failure and/or performance problems. This happens because the earlier version is incapable of using APIs and DLLs designed for use by a later version.
Interoperability Problem
As used herein, interoperability is the ability of program modules to share data. In particular, interoperability is the ability of differing “types” of program modules to share data. Program modules are different types when they are not just different versions of each other.
An example of interoperability is a Microsoft® Paintbrush application sharing data (such as a bitmap image) with a Microsoft® Office application. Regardless of version, Microsoft® Paintbrush and Microsoft® Office are different types of program modules.
It is desirable for an OS to provide this type of interoperability between different types of program modules. However, such interoperability is difficult when the program modules are different versions.
An example of such a situation is when a 16-bit version of a Microsoft® Paintbrush application wishes to share data (such as a bitmap image) with a 32-bit version of Microsoft® Office application. Not only are these program different types, but also they are different versions.
Conventional Solution
The compatibly and interoperability problems like those described above occurred when Microsoft Corporation introduced its 32-bit OS in Windows® 95. To avoid these types of compatibility problems, the new 32-bit applications were instructed to store their config-info in a different location than the older 16-bit applications. In addition, they were directed to use different names for their APIs and DLLs.
Although this did help with compatibility and interoperability, it forced software developers to redirect large resources to software conversion rather than to development of new or improved software. Because of these directions, existing 16-bit versions of software needed to be significantly modified to port it to a 32-bit version. The code needed to be altered so that it referred to different APIs and DLLs. The code needed to be altered to store config-info to a different location and access it from that new location.